It looks like this contributor signed our Contributor License Agreement. 👍

Many thanks,

Parity Technologies CLA Bot

@rphmeier explained the double hashing but I've already forgotten what it was. :/ It is indeed needed though.

My first guess would be to get an uniform address space distribution (96 bits of hashdb key are not).

There is something tricky with this removal : in our use case (archivedb) we do not want it to actually happen except at a single block level (so we can query at previous block) and it will not due to archivedb implementation.
But if we run fatdb in non archive mode, this deletion may not be what we want and we may prefer to remove those deletion lines (we will get additional false value in the db but it is only an issue for the disk space).
I am really not sure if using the fatdb without archive makes sense (parity_listStorageKeys seems to be the only method that is impacted by this suppression).
If it makes sense (non archive + fatdb), an alternate fix would be to avoid removing this association at all.

@cheme I agree that the current behaviour looks broken. I don't fully understand what the purpose of FatDB is but this test fails on master and passes on this branch (@ordian is this sort of what you were asking for?):

	#[test]
	fn insert_and_removal_leaves_the_db_empty() {
		use hashdb::HashDB;
		let mut db = MemoryDB::<KeccakHasher>::new();
		let mut root = H256::new();
		{
			let mut t = FatDBMut::new(&mut db, &mut root);
			t.insert(&[1], &[2]).unwrap();
			t.remove(&[1]).unwrap();
		}
		assert_eq!(db.keys().len(), 0);
	}

@dvdplm yes, a similar test was added already by @cheme.

@dvdplm should we publish patricia-tree 0.2.2 and update parity-ethereum and substrate as well?

Please reference openethereum/parity-ethereum#9213 when updating the dependency on parity-ethereum so that the original issue is closed. 👍

should we publish patricia-tree 0.2.2

Yes. I have pushed out 0.2.2-beta.0. When we feel confident that openethereum/parity-ethereum#9213 is fixed we'll get it off the beta. In-progress PR here.

:)